NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/17466

Internet Message Format | 1996-08-05 | 5.5 KB

Path: news.nstn.ca!news
From: [e-mail] (dbshapco)
Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
Subject: Re: OOA [was:Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer]
Date: 16 Apr 1996 01:19:42 GMT
Organization: iSTAR Navigator User
Message-ID: <4kusje$[e-mail]>
References: <[e-mail]> <4kma54$[e-mail]> <[e-mail]> <4kr166$[e-mail]> <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: ts5-06.ott.istar.ca
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.14

In article <[e-mail]>, [e-mail] says...
>
>[...]
>However, well defined taxonomies are not easy to come by.  The
>problem is that the taxonomy of the woman on the warehouse floor
>is *not* the same as the taxonomy of the guy in accounts
>receivable which differs yet again from the salesman, ad
>nauseum throughout the customer's organization.  Each person
>chops up the flow of work in a different way.
>
>    --bks

Good point.  An endemic problem in software development is the inability to
freeze software requirements, partially because the requirements are being
driven by several different sources with competing goals and agendas and
divergent ideas about what the end software product should be.  Requirements
become overloaded.  In OO, sometimes it is just a philosophical difference on
how to decompose the problem domain and sometimes people who must share
information and bridge work flows really do have completely different
perspectives that justify different taxonomies.

Usually it is because we aren't really talking about a single problem domain
that can be solved by a single piece of software (with elegance, at least,
and without shoehorning some unwilling users into the tool's paradigm, rather
than supporting their work flow).  A few different software packages that
break out each community's areas of concerns with well defined interfaces
between them helps here, laced together with DCE or CORBA or an OO/RDBMS
server (or whatever).  (The ODP concept of different perspectives on a single
system: even though inventory control, A/R and sales all need to know about
Acme Co.'s grapple grommets, they have *justifiably* different perspectives
and that product fits differently into their scheme of things.)

Usually this isn't as much added effort as it sounds, because such division
vastly simplifies analysis and looks like a win-win solution to the
independent user communities (each gets it own goals and agendas attended to
without detracting from others), a good chunk of code is common (especially
DBs, GUIs, and other such conventional stuff), and except for naming
collisions, it is fairly easy for different taxonomies to co-exist in the
software if they must (usually each taxonomy ends up in separate software).
(However, some techniques for object distribution make it difficult to in
effect say 'these objects are really different ways of looking at the same
object'.)

Another really tough part is getting people to agree where the problem domain
segments cleanly into smaller problem domains (promotes turf wars) and then
defining interfaces without dictating what lies behind the interfaces (by Use
Cases, perhaps, with each community being a 'block'; unfortunately, some
practioners try to magic up interfaces a priori without a first cut at the
problem domain analysis).  Linkages between taxonomies are difficult to
manage; taxonomies should be related only by information flow across well
defined interfaces.

Using our cooked example, sales maintains an independent idea of what grapple
grommets are and how they fit into a sales taxonomy.  When 500 of the
beasties are sold, warehousing must know to take 500 out of inventory control
and ship them to the receiver, and notify A/R for billing, again using an
independent idea of what grapple grommets are in a warehousing/inventory
taxonomy.  A/R then looks up things grapple grommets for cost, applicable
discounts, shipping rates in the accounting taxonomy.  My mind boggles
imaging trying to define a grand unified grapple grommet overloaded with all
the attributes and operation each of these domains needs.  (And obviously,
you need concensus at some level; each accountant cannot have her own private
taxonomy.)

But still, it presents unique challenges differing from monolithic
taxonomies.  (Which makes me think of, somewhat off topic, one of the more
common recent damaging trends in software development: deciding on a
distributed architecture a priori -- because somebody has just discovered
CORBA or Java in a magazine article, usually -- and arbitrarily dividing up a
perfectly monolithic architecture and taxonomy into a distributed one.  These
are usually the same development teams that spend seven weeks defining
interfaces between systems without even a fundamental analysis of the problem
domain.  Whereas problems that beg for distributed architectures motivated by
the nature of the problem domain are still being packed into a single
software package while the end users fight over the paradigm to be adopted by
the software.)

Even starting a spec with 'we require an application which' insidiously
pollutes the analysis with implementation details, because it is not yet
known that a *single* application best addresses the requirements, and the
analyst begins with the premature assumption that a *single* taxonomy is
required.

--
Brad Shapcott, Technical Consultant
Lockheed-Martin's Advanced Concepts Center
Ottawa, Canada [phone] x227